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Be it known that we, Sean Boylan, a citizen of the Republic of Ireland, residing at 21 Ros Geal, 
Millar's Lane, Rahoon, Co Galway, Ireland, Derek Coburn. a citizen of the Republic of Ireland, 
residing at Rose Cottage, Red Barnes Road, Dundalk, Co Louth, Ireland, Tadhg Creedon, a 
citizen of the Republic of Ireland, residing Coismeig Mor, Furbo, Co Galway, Ireland, Denise 
de Paor, a citizen of the Republic of Ireland, residing at 'Loch a Duilliur' Killeen Road, Carraroe, 
Co. Galway, Ireland, Vincent Gavin, a citizen of the Republic of Ireland, residing at 19 Ard 
Fraoigh, Clybaun Road. Galway, Ireland, Kevin James Hyland, a citizen of the Republic of 
Ireland, residing at 71 Castle Park, Clondalkin, Dublin 22, Ireland, Suzanne Marie Hughes, a 
citizen of the Republic of Ireland, residing at 20 Cimin Mor, Cappagh Road, Barna, Co Galway, 
Ireland, Kevin Jennings, a citizen of the Republic of Ireland, residing at Caltralea, Ahascragh, 
Ballinasloe, Co Galway, Ireland, Mike Lardner, a citizen of the Republic of Ireland, residing at 
Cloomnore, Tuam, Co Galway, Ireland and Brendan Walsh, a citizen of the Republic of Ireland, 
residing at 63 Riasc na Ri, Old Rahoon Road, Galway, Ireland have invented new and useful 
improvements in 

AUTOMATIC GENERATION OF INTERCONNECT LOGIC COMPONENTS 
of which the following is a specification 



AUTOMATIC GENERATION OF INTERCONNECT LOGIC COMPONENTS 



Field of the Invention 

This n-nention i elates to the generation of large scale integrated circuits and particularly to 
the layout of a ~sy stem-on-a-chip" 

Background to the Invention 

Theie aie \anous program tools used in the generation of large scale integrated circuits 
that use libianes of re-useable elements, examples are layout tools with memory libraries 
In the case of these tools one still has to hand-code how the mdmdual elements are 
connected together A new design using the same set of libraries elements but a different 
interconnect hierarchy or architecture requires the designer to hand code this interconnect 
logic afresh 

Summary of the Invention 

The present lmention partly relies on a library of reusable elements but automates the 
generation of the interconnect logic This permits automatic generation of new and 
different realisations of the architecture 

The preferred architecture means that substantially all data exchange between core blocks 
is \ 1a a central shared memory (or group of memories) that could be on-chip and/or off- 
chip This means thai if for example an Ethernet core and a PCI core have to pass data to 
each other then the data would be copied into memoiy from and by the Ethernet core and 
copied out of memory by the PCI core 

Access to memory- is a limited resource Preferably therefore the invention accommodates 
a hierarchical data aggregation technique whereby read and write requests go through 
successne le\ els of arbitration in order to gain access to memory This has two main 
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advantages il allows dispeisal of routing bottlenecks and enables the use of the lowest 
possible frequencv clocking for each operational function 

Prefer abh there is a separation of data paths from register paths Data handling cores 
communicate with memor> Ma a data path Register paths are between processor cores 
and other cores It is possible to ha\e multiple register paths from processor cores to 
gioups of cores This allows the grouping of cores on a particular register path based on 
such parameters as bandwidth and access latenc\ 

Brief Description of the Drawings 

Figuie 1 is a data path diagiam 
Figuie 2 is a register path diagiam 
Figure 3 is a contiol path diagram 

Figure 4 is a diagram illustrating interconnection hierarchies 
Figure 5 is a table of states for a state machine 

Figure 6 is a timing diagram for the state machine shown in Figure 5 

Figure 7 is a diagram lllustiatmg high le\ el clock functions 

Figure 8 is a diagram illustrating bridge functions 

Figure 9 is a diagiam lllustiatmg arbitration functions 

Figure 10 is a further diagiam illustrating arbitration functions 



Figuie 1 1 is a diagram illustrating bus paths 
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Figure 12 is a diagram illustiating core wrapper functions 

Figuie 13 is a diagram illustrating memon controller wrapper functions 

Detailed Description 

Foi a plurality of interconnected deuces m an s\ stem-on-a-chip or similar application, a 
scheme according to the lmention infers automatically appropriate logic functions, such 
as arbiters, inter-clock-domain boundary buffering and alignment, clocking mechanisms 
Interconnections ma} be depicted graphically or otherw ise 

The ke\ to de^ eloping systems quickh is the separation of the interconnect logic and the 
basic operational blocks, herein called -cores" These cores will not need to be altered for 
each s\stem. onh the set of cores and the wa\ the> interconnect need change The 
following description describes how the generation of this interconnect logic (which is 
preferabh expressed in HDL/ Venlog) can be automated 

The inputs needed in a preferred example to automaticalh generate the interconnect logic 
are as follow s 

A hbran of reuseable cores with ke> parameters defined, from which library cores can be 
selected. 

A set of ailes defining how cores can be connected together. 

1 Interconnect logic blocks (clock generator, arbitration, register bridge) and their 
configurable parameters. 

2 A method of describing how the cores need to be connected This could be 
achie\ed using a spreadsheet or as preferred a graphical picture showing the cores 
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and how they are connected together, as shown for example in Figure 1. Figure 2 
and Figure 3 . 

3 Generic Venlog/HDL for each of the interconnect blocks to which the parameters 
can be applied to create the specific interconnect logic for the system being 
designed 

Using these inputs a set of algorithms will be applied in order to create the system's 
mteiconnect logic There are effectn eh three generic types of algorthms that can be 
applied m order to create the logic 

(A) Parametensable Venlog/HDL - where all that needs to be done is to define the value 

of a sel of parameters 

(B) Venlog Templates are used where the same functionality needs to be repeated a 
number of times Examples are generation of select line logic ( select 1 of N blocks 
connected \ia the same bus) or multiple instances of the same interface logic (eg an 
arbitration block with 5 memory bus connections) 

(C) State Machine Algorithms wherefor all the Venlog/HDL is generated The algorithm 
decides the numbei of states in the state machine and the \alue of all signals m the state 
machine 

In order to generate the logic associated with a particular interconnect block it may be 
necessan to apply combinations of these algorithms one or more times The Venlog or 
HDL modules will be created for each of the interconnect blocks shown graphically m the 
interconnect diagrams or otherwise A top level Venlog instantiation file with be created 
incorporating each of the interconnect blocks and core wrappers This file will declare an 
instance for the generated modules (arbitration, register bridge etc) It will declare an 
instance for each of the core wrappers The Venlog instantiation file will reflect a 
completely flat hierarchy with all modules being declared at the same ley el This will be 
the starting point used to create selectable hierarchies 
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Figures 1. 2 and 3 aie diagrams illustrating specifically a data path, a register path and a 
control path for a specific system Each of them relies on the obtaining of basic elements, 
such as cores and memory interfaces, from a hbrar> and the layout tool which will be 
described later is employed to generate the interconnect logic including arbitrators and 
bridges for the selected s>stem which is to be designed using elements from the memon' 

In the data path diagram shown in Figure 1 there are two cores 10 and 1 1. denoted "Corel" 
and "Core2" respectnely and a processor core 12. denoted "Processor!" and two 
interfaces, the Memon. 1 interface 13 and the "Memon 2' interface 14 Herein the term 
"data' is used to denote the information on which the system operates In the example of a 
network switch, it is principally constituted by packet data, which may be either address 
data or message data The "register" path is essentially employed for enabling a processor 
core to control or monitor the status of other processors or cores by writing and/or reading 
signals into or out or control of status registers in those other cores or processors The 
control path is employed for such ancillary functions such as interrupts, resets and 
suchlike 

In Figure 1 Corel is to be able to direct data transactions, such as reading and writing to 
both the memory interface 13 and the memory interface 14 "Core2" is to be able to direct 
data transactions onh to the memory interface 13 Processorl can not only direct data 
transactions to the memon interfaces 13 and 14 but differs genencally from the other 
cores in that it may also exchange register transactions with registers of cores or 
processors not shown in Figure 1 

It is generalh comenient to emplo\ a register bus system which is different m 
organisation (such as in respect of number of lines, bandwidth, operating speed etc) from 
the bus s\stem which is employed for data transactions However, it is also convenient to 
emplo^. processors which produce register transactions in a form compatible with the 
memon bus sn stem If this be so. it is necessary to employ a bridge, such as "Bndgel" 
which effects translation of register transactions (data intended for writing m or read from 
registers, together with associated requests acknowledgements and control signals) to and 
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from the format required for the memory bus from and to respectively the format required 
for the register bus 

The interconnect logic as far as the data path is concerned m Figure 1 comprises various 
sections ofmemon bus. denoted mBusl. mBus2 etc and the arbitration blocks, shown as 
Arbl and Arb2 These arbitration blocks aggregate the memoty bus sections that extend 
towards the cores into a respectn e common memoiy bus section proceeding towards the 
memon . 01 anothet stage of arbitration if that be necessaiy The arbitrators need to buffer 
lequests for the reading and writing of data In general it is desirable to allow the various 
sections of the memoiy bus to ha\e a data width and/or an operating speed matched to the 
respective core The arbitrator needs to ha\e its common bus. such as mBus6 for Arbl and 
mBus7 for Arb2. capable of operating at a greater data rate than any of the indn ldual data 
rates on the buses which extend between the arbitrator and the respectn e cores 
Furthermore, the arbitrator needs to determine, for example by way of a round-robm 
algorithm, the order m which requests recened on the \arious memon- bus sections will 
be forwarded onto the respectn e memoiy interface 

Also shown in Figure 1 are clock generating circuits denoted CLK.1. CLK2 etc The 
architecture em isaged m the present in\ ention assumes that a system or parent clock will 
be subdnided to pro\ ide a local integral sub-harmonic clock for each of the cores, as 
described for example m co-pending application serial number No 0104829 3 filed 27 
February 2001 

Figure 2 is a simple example of a register path diagram wherein a "Bndgel" (e g the same 
bridge as shown m Figure 1) is coupled b\ a register bus rBusl" to target interfaces in 
two coies. 'Corel' and -Core2" The target interfaces are coupled to registers not shown 
Likewise another bridge. -Bndge2" is coupled b> a second register bus to target interfaces 
m two further cores. 'Core3' and "Core4' The diagram includes a -Null Bridge' notionally 
coupled b> a Null rBus to a target interface in -Core5" The significance of a null is that 
the respectn e target interface is not intended to exchange register transactions with the 
bus to which the 'null bridge" is connected 



Figure 3 is an example of a control path diagram showing paths of control signals between 
\ artous cores 3 1-35 and processor 36 and 37 The signal paths denote "interrupt' or "reset" 
or misc(ellaneous) according to their purpose 

Diagram Rules 

The following is a preferred list of the rules that will be enforced as a user creates the 
three diagrams (data, register and control) that describe the interconnect logic that will be 
geneiaied Rules may be added and removed from the tool as necessary or ad\ lsed 

Data Diagram Rules 

Since data transactions are com eyed by a memoiy bus (mBus) the data path will 
henceforth b> referred to as the mBus 

1 1 One ma> ha\e onh the following elements m a data diagram These are cores, 
such as the elements 10-12 a register bridge, such as 'Bridge 1" in Figure 1. mBus 
initiator ports, such as shown at 15 and 16 for Corel in Figure 1. arbiters, such as 
Arbl and Arb2 m Figure 1. mBus target ports, such as those shown at 17 and 18 m 
Figure 1 and clock generators, e g CLK1. CLK2 etc shown in Figure 1 

1 2 One must ha-\ e at least one core with an initiator port and one core with a target 
port 

1 3 One may ha\ e onh a specified maximum of cores (as explained below) 
1 4 One may 1^ e multiple instances of the same core 

1 5 A core may ha\e both an mBus initiator and mBus target interface The following 
rules will apply in this case 

a) Targets and initiator interfaces will be represented separately on the diagram 

b) Both interfaces will use the same name and unique identifier 

c) Onh one of the interfaces can ha\e a clock generator connected to it 

1 6 One may ha\e am number of arbitration, register bridge and clock generator 
blocks 

1 7 An initiator is connected to target(s) and/or register bndge(s) and/or arbiter(s) 
1 8 A target is connected from an initiator ( 1 ) or an arbiter { 1 ) 



1 ( ; A iegislei bridge is connected from initiators ) or arbiter(s) 
1 10 An arbiter is connected from mitiator(s) oi arbiter(s) 
1 1 1 An arbiter connects to arbiters ) or target(s) or register bndge(s) 
1 12 Onh processor cores will be programmed with the addresses necessary to address 
a register bus 

1 13 There should onh be one possible unique path from an mBus initiator interface to 

an mBus target interface 
1 14 Cores ma\ ha\ e multiple mBus initiator interfaces (maximum number is a library 

property ) 

1 15 A menion interface core ma\ ha\eonh one mBus target 

1 16 An mBus interface on a core that is unused will automatically have its unused 
input signals tied off 

1 17 An mBus ma\ be split so that it goes to multiple blocks. The maximum number of 
destinations is a libran, property for cores and is configurable for arbitration 

blocks 

I IS An arbitration block ma\ ha\ e am number of input ports but may haA e onh one 
output port 

Some of the aforementioned rules are formulated because the preferred embodiment of the 
m\ ention is intended to be compatible with the architecture and system of posted read and 
write transactions which are the subjects of GB patent applications numbers 0113584 7 
and 01 13601 9 both filed on 5 June 2001 Reference should be made to those applications 
for a more detailed explanation of the architecture (including aggregators and core 
wrappers) and the s>stem of posted read and write transactions For example, rule 1 3 
abo\e arises because the preferred embodiment described in the later of those two 
applications includes read and write transactions including an identification of the source 
of a write transaction or an initiator of a read transaction, the identifier being represented 
b\ a 6-bit binaiA field, sufficient to proude unique identification of up to 64 cores in the 
s\ stem Other rules (as for the rules below ) are appropriate to a^ oid ambiguit) 
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Register Diagiam Rules 

The register path will henceforth be referred to as the rBus 

The following are the rules for drawing register path diagrams as shown in Figure 2 

2 1 One ma\ add am core that has an rBus target interface 
2 2 One ma\ add am number of cores 
2 3 A core ma> appear on one rBus only 

2 4 Cores that do not require to use rBus target functionality should be placed on a 

"null register' bridge This will ensure that unused input signals will be tied off 
2 5 Cores ma\ ha\ e onh one rBus target port 
2 6 A register bridge ma\ ha\ e am number of rBus target ports 
2 7 A register bridge ma> ha\ e onh one rBus initiator port 

2 8 All cores connected to a register bridge must ha\e a clock frequenc\ greater than 
or equal to the register bridge's clock frequenc) 

The following rules apph when adding clock generation functionality to the data 
diagiams 

C I All blocks (cores, register bridges, arbiters) m the data diagram must be connected 

to a clock generator block 
C 2 Blocks that run at the same clock frequency can be connected to a common clock 

generator block 

C 3 A clock generator block dernes its required clock frequency from the s>stem clock 
unless specifically connected to another parent clock generator, m which case its 
clock frequency is derned from the parent block's clock frequency 

C 4 A clock generator can be used as a parent if (a) none of the blocks below it in the 
interconnect hierarchy talk directh to am other blocks at a higher le\el and if (b) 
all blocks below it in the interconnect hierarch> can ha\e their clock frequenc> 
dem ed horn it 
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The rules for clock generators are. as indicated above, would generally apply but are also 
intended to render the specific clock s\stem compatible with the s\stem described m the 
aforementioned application No 0104829 3 

Control Diagram Rules 

3 I All cores that ha\e am non-data (mBus) or register (rBus) signals will appear m 
the control diagram These signals will henceforth be referred to as controls signals 
and include such signals as interrupts and special purpose configuration signals 

3 2 One ma\ connect input signals onh to output signals 

3 3 One ma\ connect signals of the same width only 

3 4 Unused signals w ill be automatically tied off 
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Intei connect - Block Parameteis 

The following is a pieferred list of the parameters that ma} be programmable for each of 
the interconnect logic blocks Parameters can be added and removed from the tool as 
necessan The parameters will ha\ e default -sallies that will either be extracted from the 
associated core librar> properties or else inferred from a connection shown on one of the 
three diagrams (data, register or control) 

The following abbre\ lations are used to specif} parameter behaviour 

• RW - The parameter can be read and written to b\ the tool 

• RI - The \alue of the parameter is inferred from one of the interconnect diagrams The 
\ alue of the parameter can be read 

• I - The \ alue of the parameter is inferred from the one of the interconnect diagrams 

• R - The \ alue of the parameter can be read and its ^ alue is taken from the core library 

The parameters define what is configurable The\ do not place any restrictions on how the 
parametensed Venlog is created 

Table 1 below shows examples of global system parameters b\ name, \alue. t\pe and 
description Table 2 and Table 3 similarly show the parameters for a clock generator 
block 



TABLE 1 



Parameter Name 


V alue 


Type 


Description 


System Clock 


Integer 


RW 


This is the master clock that is sent around the 
chip to create lower frequencies clocks The 
stem clock w ill have a default -s alue of 200 


Ma\_Burst_Si/e 


Integer 


RW 


The maximum burst size (read or write) 
which is allowed on the mBus The default 
maximum burst size will be 32 
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TABLE 2 


Parameter Name Value 


Type ; Description 


Block Name 


Siring 


RW 


All blocks in the diagram must have a unique 
name The block name will be used m the 
generation of Venlog signal names etc The 
default name vull be "Clk#~ 


ParentClock 


Integer 


RI 


This will be either the system clock or the 
output from another clock generator block 
The ClockJFrequency used bv connected 
blocks will be generated from it 


Is Logic_Block 


Boolean 


RW 


If this parameter is true then a Logic_Clock 
will be generated and must be used by all 
connected blocks. The default value is False 


Clock_Frequnc> 


Interger 


RW 


The clock frequency at which the logic of 
blocks connected to this Clock Generator will 
run at The Svstem_Clock must be an integer 
multiple of this \alue 



The design tool will traverse the data diagram to create an arra> of divide bv numbers for 
each lower frequency block connected to the set of blocks for which this clock generator is 
generating a clock frequencv The "div ide b> " ratio arrav will be used m the generation of 
sample and strobe signals The parameter is shown m Table 3 



TABLE 3 

10 



Parameter Name 


Value 


Type 


Description 


Div ide_Bv _Ratio [ n ] 


Integer 
Arrav 


I 


The divide by ratio of each connected block 
of lower frequency The divide by ratio is 
calculated by div iding the Parent_Clock value 
bv the Clock_Frequency of the lower 
frequencv block 
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Table 4 through to 7 illustrate the parameters for an arbitration block 



TABLE 4 



Parameter Name 


Value 


Type 


Description 


Biock_Name 


String 


RW 


All blocks m the diagram must ha\e a unique 
name The block name will be used m the 
generation of Venlog signal names etc The 
default name will be 'Arb#" 


Clock Frequency 


Integer 


RI 


The clock frequency at which the logic 
associated with this block will run at The 
S\ stem_Clock must be an integer multiple of 
this \ alue 


No_Of_Ports 


Integer 


I 


This value is inferred from the data diagram 
Each arbitration block will initially have 2 
input ports and one output port 


SID_To_Port_No [ n ] 


Integer 
Array 


I 


An entry in the hash table or arra\ will exist 
for all cores below this arbitration block m the 
interconnect hierarchy Source Identifiers are 
used on the return path of the mBus to 
identify the Source of a read or write request 


Required_Band\\ ldth 

i 


Integer 


RW 


The bandwidth required by this arbitration 
block The default value for 
Required_Band width is calculated b\ 
summing the allocated bandwidth at each of 
the arbitration block's input ports 



Each mBus input port in an arbitration block will ha\e two npes of buffers - 

Up_Buffers store mBus read and write requests going up the interconnect hierarchy 
towards an mBus target The size of some of the Up_Buffers is fixed (rdCmdData and 
rdCmdPhase) and the size of others is a anable (wrlnfo. wrPhase. wrData) The minimum 
size of the \ anable Up_Buffers is dependent on the s\ stem's Max_Burst_Size 

Down_Buffers store mBus read responses going down the interconnect hierarchy towards 
mBus initiators The size of the Down_Buffers is \ anable (rdDataPhase. rdData. 
Hold_buffer) The minimum size of the \ anable DownBuffers is dependent on the 
s\stemsMax Burst Size 



The rele\ ant parameters for an mBus input port are shown in Table 5 below 
TABLE 5 



Pit rcimptpi' TVn nip- 


Value 




Description 


Bandw idth_Allocalion 


Integer 


RW 


The bandwidth to be allocated by the 
arbitration block to this mBus input port The 
default ^ alue will be inferred from the block 
connected below it m the interconnect 
hierarch\ The default \ alue will be the lesser 
of the following two \alues 
Required_Bandwidth or Output_Band\vidth 
An arbitration block w ill ha\ e a set number of 
slots Each Input port will be gnen a set 
number of slots based on its bandwidth 
allocation \ alue 


r J 1 vH 1 1 \ 

i 


Enum 


RW 


The priontA associated with this mBus input 
port It can be one of four possible \ alues - 
Low Latenc\. High Priority, Low Priority or 
Normal Pnorit\ . 


| Mm_Buffer_Size 


Integer 


RI 


This is the minimum size of the buffers for 
this mBus input port The buffers cannot be 
decreased below this size The \alue is 
inferred from the diagram b> multiplying the 
Max Burst Size by the mBus_Width 
associated w ith this port 


Up_Buffer_Size 


Integer 


RW 


The integer number of storage locations in the 
Up Buffers The size of each storage location 
is dependant on the specific buffer and the 
mBus Width of the port It can never be less 
than Min Buffer_Size. which is its default 
\ alue 


Up_Buffer_Assert 


Integer 


RW 


How full the Up_Buffer needs to be before 
one can attempt to pass information up the 
interconnect hierarchy 


Up_Buffer_Accept 


Integer 


RW 


The number of storage locations that need to 
be a\ailable in the Up_Buffers before the\ 
will accept new information 
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Down Buffei Si/e 


Integer 


RW ' 


The integer number of storage locations in the 
Down Buffers The size of each storage 
location is dependant on the specific buffer 
and the mBus_Width of the port It can ne\er 
be less than Mm_Buffer_Size which is its 
default value 


Is_Throltled 


Boolean 


RW 


This will stop requests being sent up from the 
corresponding Up Buffer if the Down Buffer 
is full It will default to False in most 
arbitration blocks It will default to True for 
arbitration blocks directly connected to mBus 
targets 


The parameters for mBus output ports are shown in Table 6 below 
TABLE 6 


Parameter Name 


Value 


Type 


Description 


Output_Bandw ldth 


Integer 


RJ 


The bandwidth a\ ailable at this mBus Output 
port The \alue is inferred from the diagram 
b\ multiphing the Clock_Frequenc> of the 
arbitration block b\ the BusJVVidth of this 
mBus 


Bus_Width 


En urn 


RW 


The width of this mBus The supported \alues 
are 8.16.32 and 64 The default ^alue will be 
32 


Duple\_Mode 


Enum 


RW 


The duplex mode of the mBus The supported 
values are Half. Full The default \alue will 
be Half 


Addressable_Targets 
[ n ] [ 3] 


2 -Dim 

Integer 
Arra\ 


I 


This array or hash table will define the upper 
16 bits of the Base_Address of all mBus 
targets reachable through this output port All 
mBus target memories are contiguous so the 
base address of each target is sufficient to 
uniquely identify it It will store the input port 
of the higher level block through which the 
mBus target is accessible (mBus can be split 
to multiple destinations) 



The parameter for a rBus half-duplex target port is shown in Table 7 below 



TABLE 7 



Parameter Name 


Value 


Type 


Description 


Address_Bits_Decoded 


Integer 


RI 


The number of address bits decoded defines 
the number of registers in this arbitration 
block The \ alue is inferred from the diagram 



Is_Throttled will be turned on b> default in am arbiter connected to an mBus target 
(memor> or register bridge), it will be turned off by default in all other arbiters 
Arbitration blocks directh connected to a memory interface preferably ha\e a 64 bit wide 
output mBus 



The parameters for a register bridge (with in-built arbitrator) are shown m Tables 8 
through to 10 

15 

TABLE 8 



Parameter Name 


Value 


Type 


Description 


Block_Name 


String 


RW 


All blocks in the diagram must have a unique 
name The block name will be used in the 
generation of Venlog signal names etc The 
default name will be 'Bndge#' 




Clock_Frequenc\ 


Integer 


RI 


The clock frequency at which the logic 
associated with this block will run at The 
System_Clock must be an integer multiple of 
this , \ alue 


No_Of_mBus_Ports 


Integer 


I 


This a alue is inferred from the data diagram 
A register bridge will initially have 2 mBus 
target ports 


Base_Address 


Integer 


RW 


The base address of this mBus target 

j — — 



The parameter for a rBus half-duplex initiator port is shown m Table 9 
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TABLE 9 



Parameter Name 


Value 


Type 


Description 


Bus Width 


Enum 


RW 


The width of the rBus. The supported values 
are 8.16.32 and 64 The default value will be 
32 The same rBus will be fed to all rBus 
targets connected to this register bridge 


Foi each of the iBus targets connected to this register bridge one will store the parameters 
shown in Table l(> 

TABLE 10 


Parameter Name 


Value 


Type 


Description 


Start_Address_Offset 


Integer 


I 


Used in the selection of an rBus target 
connected to this register bridge Each rBus 
target has a sequential range of valid 
addresses The start address of this range is 
calculated by adding the 
Start_Address_Offset to the Base_Address of 
the register bridge 


End_Address_Offset 

i 


Integer 


I 


Used m the selection of an rBus target 
connected to this register bridge Each rBus 
target has a sequential range of valid 
addresses The end address of this range is 
calculated b> adding the End_Address_Offset 
to the Base Address of the register bridge 



The register bridge arbitration algorithm will preferably be fixed as round-robin This 
means that it does not require am buffering and that there is no concept of bandwidth 
allocation on the rBus bus The rBus will preferably alwa\s operate in half-duplex mode 
The total bandwidth on the rBus is defined as (Register Bridge ClockJFrequency * 
Bus_Width) 



The parameters for a core block are shown in Tables 1 1 though to 16 
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TABLE 1 1 



Parameter Name j Value 


Type 


Description 


Block_Name Strm S 


RW 


All blocks in the diagram must ha\e a unique 
name The block name will be used m the 
generation of Venlog signal names etc lne 
default name will be dern ed from the core's 
hbrar\ property 


Clock Frequenc\ 


Integer 


RI 


The clock frequency at which the logic 
associated with the core wrapper will run at 
The S\stem_Clock must be an integer 
multiple of this \ alue 


Source Code Directors 


String 


RW 


Where the source code for this core is stored 
The default \alue will be taken from the 
core's library property 


No_Of_mBus_Target_P 
orts 


Integer 


I 


Number of mBus target ports supported The 
value cannot be greater than the library 
property but mBus ports can be left unused. 


No_Of_mBus_Imtiator_ 
Ports 


Integer 


1 


Number of mBus initiator ports supported 
The value cannot be greater than the library 
property but mBus ports can be left unused 


mBus T>pe 


En um 


R 


Denotes mBus target or an mBus Initiator 
Supported \alues are Target. Initiator The 
\alue is taken directly from the core's library 
propertv 


The parameters for an mBus initiator core are shown in Table 12 
TABLE 12 


Parameter Name 


Value 


Type 


Description 


Source Identifier 

i 


Integer 


RI 


This will be a value in the range [0-63] 
Source Identifiers are used on the return path 
of the mBus to identify the Source of a read 
or write request mBus targets will not be 
allocated a Source Identifier 


Is_Processor 


Boolean 


R 


This value will be set to True if this core is a 
processor The value is taken directh from 
the core's library property. 



The parameters for a core wrapper's mBus initiator ports are shown m Table 13 



TABLE 13 



Parameter Name 


Value 


Type 


Description 


Bus__Width 


En urn 


RW 


The width of this mBus The supported \alues 
are 8.16.32 and 64 The default -\alue will be 
32 


Duple\_M°de 


En urn 


RW 


The duplex mode of the mBus The supported 
\ alues are Half. Full The default \ alue will 
be Half 


Required Bandwidth 


Integer 


RW 


The bandwidth required by the Core on this 
mBus Output port The default value is taken 
directh from the core's library propert} 


OutputJ3andwidth 


Integer 


RI 


The bandwidth available at this mBus Output 
port The value is inferred from the diagram 
b\ multiph ing the Clock_Frequency for the 
Core bv the Bus Width of this mBus 


Addressable Targets 
|n||3| 


2 -Dim 
Integer 
Arra\ 


I 


This arra> or hash table w ill define the upper 
16 bits of the Base_Address of all mBus 
targets reachable through this port All mBus 
target memories are contiguous so the base 
address of each target is sufficient to uniquely 
identify it It will store the input port of the 
higher leA ei block through w hich the mBus 
target is accessible (mBus can be split to 
multiple destinations) 



The parameters for an mBus target core are shown in Table 14 



TABLE 14 



Parameter Name 


Value 


Type 


Description 


Base_ Address 


Integer 


RI 


The base address of this mBus target 
Initiators will not have a Base Address 


Addiess_Offset 


Integer 


RW 


The size of the addressable raemon The 
default \alue is taken directh from the core's 
lib ran prop em 


Is_Memon ^Interface Boolean 


R 


This ^alue will be set to True if this core is a 
memon interface The \ alue is taken directh 
from the core's lib ran property 
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The parameters for a core wrapper's mBus target ports are shown m Table 15 
TABLE 15 



Parameter Name 


Value 


Type 


Description 


Bus_Width 


Enum 


RW 


The width of this mBus The supported \alues 
are 8.16.32 and 64 The default ^ alue will be 
64 


Duple\_Mode 


Enum 


RW 


The duplex mode of the mBus The supported 
\alues are Half. Full The default value will 
be Half 


Bandw idth_Allocation 


Integer 


RW 


The bandwidth to be allocated b\ the mBus 
target to this mBus input port The default 
value is taken directly from the core's library 
propertv 


Memory _Band w ldth 


Integer 


R 


The bandwidth a-sailable to memory. The 
default ^^alue is taken directly from the core's 
hbran propem 



The parameters for a core w rapper's rBus half-duplex target port is shown m Table 16 
TABLE 16 



Parameter Name 


Value 


Type 


Description 


Address_Bits_Decoded 


Integer 


RI 


The number of address bits decoded defines 
the number of registers in this block The 
value is inferred from the diagram 



Signals 

15 

The Venlog source code for a core will be interrogated and at least the following \a\ues 
will be extracted for each signal 
(0 Signal Name 
(n) Signal Width 
20 (in) Signal Direction 

(i\ ) Is it an External Signal (Pin out) 

(\ ) Value to tie an Input signal to if it is unused 
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Signal T)pe mBus. rBus. other 
Connections / Bus Paths 

It is possible to specifs a unique name for all the possible connection on the diagrams 
Table 17 shows one such scheme 



TABLE 17 



Connection Type 


Default Name 




mBus 


Block Name J _ Block Name 2 _M 


rBus 


Register Bridge name "_R 


Clock Line 


'Clock Frequency' Clk 


Parent Clock Line 


'Clock Frequency' PClk 



Reus ab le _Coje Lib i an . _ Pro p erties 

Table 1 8 illustrates the t\ pe of properties that \ull be stored for each core in the library 
TABLE 18 



Core Name 



Range of clock frequencies supported - (used to decide if logic clock needed) 

Is this an mBus Initiator, an mBus target or both 

Number of mBus target ports 

Number of mBus initiator ports 

Is it a processor'' 

Is it a memoiy interface'' 

Is full source code a\ailable*' 

Source code storage area 

Description of core functionality 
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Estimated gate count 

Process geometry supported 
Estimated power consumption 
Core internal frequencx 

Table 19 illustrates the type of properties preferabh defined for each mBus initiator port 
on the core 

TABLE 19 

Bus widths supported 
Duplex modes supported 
Required bandw idth 

Maximum number of selectable mBus destinations 

Table 20 illustrates the ty pe of properties preferabh defined for each mBus target port on 
the core 

TABLE 20 

Bus widths supported 
Duplex modes Supported 

Table 21 illustrates the type of properties preferably defined for each mBus target 
TAB L E 21 

Cnerall bandwidth to memory 
Size of the addressable memory 
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Table 22 llhistiates (he r> pe of properties preferabh defined for each rBus half-duplex 
target 

TABLE 22 



Number of bits decoded which defines the number of registers in the core 



A memon map assumes a fixed address size of 32 bits but can easily be modified to 
support a 64-btt address size The memon map will allow one to specify the base address 
of each block with one or more mBus target ports The mBus targets would be extracted 
from the data diagram .An mBus target can be memon. a register bridge or a mailbox 
memon All base addresses should be aligned at a 64K boundan 

Ordinary Memory Address Pool size 

The size of the address pool assigned to normal memon should be configurable The size 
of the memon addiess pool can be incremented in 64 kl increments 

Register Bridge Address Pool Size 

Register bridges fun e a minimum address pool size The allocated pool is configurable 
abo\e the minimum size It will be possible to calculate this minimum size from the 
register path diagram d e number of rBus targets connected to the register bridge) 

The register address pool size assigned to each rBus target on a specific rBus is 
constrained by the rBus target w ith the greatest number of registers on that bus The size 
of the register address pool assigned is 

The smallest n such that (2 n < =m) where m is the numbei of registers in the rBus target 
which has the largest number of registers on this rBus 
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Thus the majority of the rBus targets \mI1 be over allocated The rBus targets will only 
look at the bits necessan to uniqueh select one of its internal registers Eg n = 6 or each 
core is allocated an address pool of 127 addresses If a core has onh three registers it will 
on!\ look at the two lowest order bits 

The addiess bus width on the rBus can be up to 32 bits wide In practice howe\er the 
legistet budge will onh feed out the numbei of address bits necessan to uniqueh select a 
coie attached to its iBus 

The pool of memon addresses assigned to a register bridge will always be an integer 
multiple of 64k Then the size of the memory pool assigned to the register bridge will be 
at least Z = (I2 n )+G where ((I2 n )+G) % 65535 = 0 and there will be G unused 

addresses 

Calculating the number of registers in a block 

The number of registers in a core is taken directly from the core's library property The 
number of registers in an arbitration block can be calculated using the formula (or 
something similar to this) \+p(q) where \ is the number of internal registers, p is the 
number of input ports and q is the number of registers at each input port 

Note All memoiy must be aligned on 64K boundaries because the arbitration blocks only 
look at the top 16 bits of an address in order to decide on which path an mBus target is 
located 

Generation of Interconnec t Logic 

Figure 4 shows two interconnect hierarchies and so how the same set of cores selected 
from a lib ran of resusable cores can be connected in radically different ways Product 
teams decide on the functional logic required in a new ASIC (i e which cores need to be 
selected from the hbran ) 
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More particularh Figure 4 illustrates the two different interconnect hierarchies which can 
be constructed using the same set of re-usable "cores' obtained from the hbran In each 
case the selection of cores from the library is a processor core 40. an Ethernet core 41. a 
PCI core 42 and a memon interface 44 

In the first interconnect hierarchy shown m Figure 4. the idea is that the processor 40 
should be able to initiate read or write transactions on a memon' bus to the memon 
interface and should be able to initiate register transactions b\ \\a\ of the bridge 43 to the 
Ethernet core 4 1 and the PCI core 42 

In the second interconnect hierarch\ shown in Figure 6. the processor 40 and the Ethernet 
core 41 can initiate data transactions on a memon bus to the memon interface 44 and the 
processor can initiate register transactions for the PCI core 42 by wa> of bridge 43 

Example of Pseudo-Code 

The following pseudo-code describes the top-le\el steps used to automatically generate 
the interconnect logic New interconnect block ty pes may be added to the interconnect in 
the future The top-le\el design will allow new elements to be added easily Functionality 
ma\ be added to or ren^ ed from the interconnect blocks m the future 

CLK_BLK[ J = arra\ of clock generator objects of size NO_CLK_BLK 
REG BLKf } = ana\ of register bridge objects of size NO_REG_BLK. 

ARB_BLK.[ | = arra> of arbitration objects of size NO ARB BLK 
IPWRAPPERf ] = arra\ of core w rapper objects of size NO_IPWRAPPER_BLK 
VALID = Boolean \alue used to decide if the interconnect hierarchy is \alid 

VALID = Validate Interconnect Hierarchy! ) 
If (VALID == 0) 
Exit 

For (n=0) -> (n = NO CLK BLK-1) 
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Create Clock Logic! CLK_BLK|n] ) 

Add lo Instantiation File ( CLK_BLK[n] ) 
Foi (n=(>) -> (n = N0_REG_BLK-1) 

Create Bridge Logic ( REG_BLK[n] ) 

Add to Instantiation File ( REG_BLK[n] ) 
For (n=0) -> (n = NO_ARB_BLK- 1 ) 

Create Arbitration Logic ( ARB_BLK[n] ) 

Add lo Instantiation File ( ARB_BLK[n] ) 
For (n=0) -> (n = NO_IPWRAPPER_BLK-l) 

Create IP Wrapper Logic ( IPWRAPPER[N] ) 

Add to Instantiation File ( IPWRAPPER[N] ) 

Validation oflnteiconnect Hieiarch\ 

The interconnect hieiarch> is a ahdated before am Venlog is generated The tool checks if 
am architectural assumptions, interconnection rules or clock generation rules are broken 
The tool will automatically enforce certain rules as a designer inputs information (i e 
parameter \alue ranges, connections between blocks) The following is a list of the checks 
that can only be performed once the diagrams are complete and the user wishes to 
generate Venlog 

1 Each rBus path has at least one rBus target interface connected to it or stated another 
w ay each register bridge has at least one core connected to it in the register diagram 

2 There are no more than the specified maximum number of cores 

3 Only processor cores are programmed with register bridge addresses 

4 There is onh one unique path from an mBus initiator to an mBus target or stated 
another way there are no loops m the diagram All paths start with an initiator and end 
w ith a target 

5 All blocks in the diagram are connected to a clock generation block 

6 If a clock generator is used as a parent then the following two conditions must hold (a) 
none of the blocks below it in the interconnect hierarchy talk directly to am other 
blocks at a higher le\el and if. (b) all blocks below it m the interconnect hierarchy can 
ha\e their Clock_Frequency demed from it 
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7 The memorx map has been correcth defined, there are no o\erlappmg areas and that 
an\ resened addresses ha\e not been assigned (Eg initial boot address of a boot 

piocessoi ) 

The \ahdation stage will also generate warnings It would be possible to change the 
se\ent\ of a warning so that it could stop the generation of Venlog The following is a 
non-e\hausti\ e list of these warnings 

1 An> parameter is still set to a default \ alue 

2 Unused interfaces/signals exist \\ ithin a wrapper (mBus. rBus or control signals) 

3 The required bandwidth for an arbitration block is greater than its output 
bandwidth (freq * bus width) 

4 The required bandwidth is greater than the output bandwidth on am mBus initiator 
port 

5 The sum of the bandwidths allocated is greater than the memory bandwidth of an 
mBus target 

Creation of Clock Loaic 

The following pseudo-code describes the high le\el steps used to create the logic for a 
clock generator block The parameters used in the creation of clock logic are fully 
described pve\ loush 

NAME = Unique name for this Clock Generator Block 

CLKJFREQ = Clock frequency generated by block 

PARENT_CLK = Parent Clock used to dem e the generated Clock frequenc\ 
IS_LOGIC_CLK = Boolean \ alue which specifies if a Logic Clock should be 
generated or not 

CLK SIGNALS [ ] = arra\ of objects from the blocks connected to the Clock 
Generator of size CONNECTIONS Holds information such as 
di\ ide b\ ratios etc 

Clock Edge Identification (CLK_RATIOS[ ]) 
Foi <n=u) -> tn = CONNECTIONS- 1 ) 
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Choose CLK dn ide Function (CLK_RATIO[n].IS_LOGIC_CLK 

Create the Clock State Machine ### 
For (n=U) -> (n = CONNECTIONS-1 ) 

Clk Generation Algoiithm (CLK_SIGNALS[n]) 
Strobe Signal Algouthm (CLK_SIGNALS[n]) 
Sample Signals Algorithm (CLK_SIGNALS[n]) 
Create Clock Out Interface ( n ) 

Di\ ide-b\ ' Clocks 

Algorithms for generation of any "divide-by' clock to be used m the architecture and 
algorithms for the generation of strobe. ClrStrobe and sample signals may be as follows 

Algorithm for Clock Edge Identification 
A. B = diude-b} numbers 

if(a%2 = = 0)| | (B°o2 = = (>) 

NO_OF_STATES = Lowest Common Multiple (LCM) of A & B 

else 

NO_OF_STATES = LCM of (A & B) * 2 

NO_OF_EDGES = (NO_OF_STATES) I A 

POS_EDGE = arra\ of size NO_OF_EDGES 
NEG EDGE=amn of size NO OF EDGES 
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Choose Clock Dn ide Functions (Clock T\ pe A) 

Chooses which CLK equation CLK_TYPE_A belongs to based on whether A & A/2 are 
e^en numbers Also chooses logic CLK. if LOGIC flag is high 

if A%2 = 0 j 

if A/2 (> -o 2 = 0 [A is an even number] 

CLK_TYPE_A = EVEN_EVEN [A is cm even number] 

else 

CLK_TYPE_A = EVEN ODD [A is cm odd number]] 
else J I A is an odd number] 

if (A-l ) , 2 % 2 = 0| 

[The number below A = EVEN-EVEN CLK] 

CLK_TYPE_A = ODD_EVEN 

if LOGICA [If Logic flag is high] 

[Logic CLK of type ODD EVEN _L] 
CLK TYPE AL = ODD_EVEN_L 

else 

CLK TYPE AL = NULL 

i else { 

[The number below A = EVEN-ODD CLK] 
CLKJfYPEA = ODDODD 
if LOGICA 

[Logic CLK of type ODD ODD _L ] 

CLK_TYPE_AL = ODDODDL 

else 

CLK_TYPE_AL = NULL [Do not create Logic CLK] 
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EVEN lo EVEN CLKS 

Creates two arra> s detailing the SYSCLK edges which ha\ e POSEEDGEs / NEGEDGEs 

5 for (n=0) -> (n = NO_OF_EDGES - 1) 

POSEDGE[n| = nA+l 

for (n=l ) -> (n = NO OF EDGES) 
NEGEDGE[n-l] = A(2n-l)/2 

in 

EVEN to ODD 

for (n=0) -> (n= NO_OF_EDGES - 1) 
POSEDGEfnl = n A + 1 

15 

for (n=l)->(n = NO_OF_EDGES) 
NEGEDGE|n-l] = A(n+l)/2 

ODD to EVEN 

20 

for (n=0) -> (n = NO_OF_EDGES - 1) { 
if (n°„2 = 0) 

POSEDGE[n] = A n + 1 

else 

25 POSEDGE[n-l] = An 
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< 
s 

for (n=l) -> (n = NO_OF_EDGES - i) | 
if (n°o2 = 0) 

NEGEDGE|n-l | = [ A <2n-l ) +L] 12 
5 else 

NEGEDGE[n-l| = [A (2n-l)-I] 12 

i 

ODD to ODD 

10 for (n=0) -> fn = NO_OF_EDGES - 1) { 

if (n%2 = 0) 

POSEDGE[n] = A n + L 

else 

POSEDGE[n-l] = An 



for(n=l)->(n = NO_OF_EDGES- 1) { 



if (n%2 = 0) 



NEGEDGEfn- 1 ] = fA (2n-l) - 1] 12 



else 



2i) NEGEDGE[n-l] = [A (2n-l) + 1] 12 

i 



ODD to ODD Logic Clock 



foi (n=0) -> (n = NO_OF_EDGES - 1) 
POSEDGE[n| = A n + I 



foi (n=l)->(n = NO_OF_EDGES){ 
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if (n°o2 = 0) 

NEGEDGEfn-1] = [A (2n - 1 ) + 1] 12 

else 

NEGEDGE[n-l] =[A(2n- l) + 3] 12 

i 

ODD to EVEN Losjic Clock 

for (n-0) -> (n = NO_OF_EDGES - 1 ) 
POSEDGEfn] = An- 1 

foi (n=l) -> (n= NO_OF_EDGES) { 
if (n°o2 = 0) 

NEGEDGE[n-l] = [A(2n- 1) + 3] 12 
else 

NEGEDGE[n-l] - [A(2n - 1) + 1] 12 

t 

Algorithm for CLK. Generation 

Generates the CLK pulses based on the numbers associated with the POSEDGE and 
NEGEDGE arra\s For hand-designed state machines, there is sufficient information m 
the abo-\ e blocks to generate the state table outputs for these clocks 
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CLKA[0] =0 
PREV CLK = 0 



foi (> = 0) -> <> = NO_OF_EDGES - 1) { 

for (n = L ) -> (n = NO_OF_STATES) { 
if(POSEDGE[\] ==n) 

CLKAjn] = 1 
else if (NEGEDGEb] == n) 
CLKA[n] - 0 

else ! 

CLKAfnj = PREV_CLK 
PREVCLK = CLKA[n] 

! 
I 



Algorithm for Generation of Strobe Signals 
Strobe Signal 

Generates the strobe signal based on the rule 1 st (fast) POSEDGE after (si cm) 
NEGEDGE 

PREV_STROBE = 0 value of Strobe signal m previous state 

PREV_A = 0 value ofCLKA m previous state 

PREV_B = 0 value ofCLKB in previous state 

for (n = 0) -> (n = NO_OF_STATES - 1 ) { 

CURR_A = CLKA[n] assigns CURR_A the current value ofCLKA 

CURR_B = CLKB[n] //assigns CURR_B the current ^ alue of CLKB 

if (PREV_A == 0) && (CURR_A ==!)&& (PREV_STROBE == 1) 
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STROBED = 1 data strobed on this edee 



if (PREV_B == 1 ) && (CURR_B == 0) 

STROBEf n ) = 1 sets Strobe on NEGEDGE of CLKB 

else if (PREV_A = 1 ) && (CURR_A = 0) && (STROBED) 

STROBE| n ] = ( ) Clears Strobe on NEGEDGE of CLKA 

else 

STROBE[nl = PREVSTROBE //set Strobe to pre^ value 

PREV_A = CLKAfn] sets PREV A to current CLKA value 

PREV_B = CLKB[n] sets PREVJB to current CLKB value 

PREV STROBE = STROBE(n] sets PREV STROBE to current STROBE value 



Strobe Signal (fast Logic CLK) 

Generates the strobe signal when the faster block has a logic CLK Variation on the rule 
for l/f -> l/fCLKs 



POSEDGE (fast Logic CLK) before 1 st NEGEDGE (fast Logic CLK) after NEGEDGE 
(slow I/F CLK) 



PREVSTROBE = () value of STROBE in previous state 

PREV_AL = 0 value of CLKAL in previous state 

PREV_B = 0 value of CLKB in previous state 

BJMEG = 0 stores a value related to a CLKB NEGEDG 
NEXT_EDGE_AL = 0 flag that controls the strobing edge of 



for (n = 0) -> <n = NOOFSTATES- 1 ) { 

STROBEfn] = u ^et all n STROBEs to ()(unless ovei-wruten) 



CURR_AL = CLKAL[n] 



current value of AL 
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CURR_B = CLKJBfn] 



current value of'B 



if (PREV_AL = ())&& (CURR_AL = 1) 



POS VALID AL = n 



setPOS VALID AL on CLKAL POSEDGE 



else if (PREV_AL = 1 ) && (CURR AL = 0) 

POS_V AL I D_AL = ( > reset POS_ I ALIDAL on CLKAL NEGEDGE 

if (PREV_B = 1 ) && (CURR_B = 0) | 
if (POS_VALID_AL != 0) | 

B NEGEDGE - POS_VALID_A not zero 

overwrite the values for Strobe at the two indexes 
given here, and set B_NEG to n. 
STROBE[POS_VALID_AL-l] = 1 
STROBE[POS_VALID_AL] = 1 
B_NEG = n 
} else if (POS_VALID_AL= 0) { 
STROBEfn] = 1 // POS_VALID_AL has been set to 0 
NEXT_EDGE_AL = 1 set NEXT_EDGE_AL and BJNEG 

B NEG = n 



if (PREV AL = 0) && (CURR_AL = 1 ) &&(NEXT_EDGE_A = 1) { 
if POSEDGE CLK.4L and NEXT EDGE is 1 
/ keep STROBE high from the value of BJNEG to 
for (i = B_NEG) -> (i = n) 

STROBE [l] = 1 the current state 

NEXT_EDGE_AL = 0 reset all flags 

POS_VALID_AL = 0 

B NEG = 0 



PREV_AL = CLKALfn] 



set previous CLKs to current CLKs 



- 36 - 



PREV_B = CLKB[n 



Algorithm for Generation of ClrStrobe Signal 

Generates the ClrStrobe signal This signal is asserted two CLK ticks before a slow CLK 
NEGEDGE. and de-asserted on the NEGEDGE itself ClrStrobe is used to o-\ernde the 
Lstrobe internal signal p^enting a node from Strobing data a clock tick before the 
NEGEDGE of the slowei block with which it is communicating 

PREV_CLK_B = 0 
CURR CLK B = 0 

for (n = 0) -> (n = NO_OF_STATES - 1) { 
CLKA[n] = O 

if (PREV_CLK_B == 1 ) && (CURR_CLK_B == 0) { 
CLKA[n-2] = 1 
CLKA[n-l] = 1 



PREV CLK B = CURR CLK B 



Algorithm for Generation of Sample Signal 



This algorithm produces the sample signal based on the rule 



(fast) POSEDGE before C (fast) NEGEDGE after (slow) POSEDGE 



PREV A = 0 



value ofCLKA in previous state 



PREV B = 0 



value of CLKB m previous state 
identifies correct sampling edge 



NEXT EDGE A = (> 
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foi (n = 0)->(n=NO_OF_STATES-I) { 

S AMPLE [n] = 0 sample signal set low m every state 

CURR_A = CLKA[n] assigns CURR A the current value of CLKA 

CURR_B = C LKB[n] assigns CURR_B the current value of CLKB 

5 

if (PREV_A = <>)&& (CURR_A = 1 ) 

POS_VALID_A = n state which a valid posedge of A occurs 

if (PREV_B = 0) && (CURR_B = 1 ) { 
10 if (POS_YALID_A = 1) 

omv/'m rues previously stored values of sample 
hased on POS I ALIO signal 
SAMPLE [POS_VALID_A - 1] = 1 
SAMPLE [P0S_VALID_A] = 1 
15 POS_VALID_A = 0 

! else if (POS_VALID_A = 0) { 

NEXT_EDGE_A = 1 sample data on next POSEDGE of A 

if (PREV_A = ())&& (CURR_A - 1) && (NEXT_EDGE_A = 1) { 
2o SAMPLE[n-l] = 1 sample signal high for 2 ticks 

S AMPLEfn] = 1 // NEXT EDGE flag is set 
NEXTEDGEA = 0 

i 

PRJEV_A = CLKA[n] sets PREV_A to current CLKA value 

25 PREV B = CLKBjn] sets PREVJB to current CLKB value 

i 
i 

Sample Signal (slow Logic CLK) 

This generates the sample signal when the slower block has a logic CLK Variation on the 
30 rule for i/f -> l/f CLKs 
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POSEDGE (fast CLK) before P' NEGEDGE (fast CLK) after NEGEDGE (slow Logic 
CLK) 

SAMPLE is set low on e\er\ n. and ma\ be overwritten b\ the process described here 
Checks for POSEDGE of fast CLK Stores VALID, and the SYSCLK number associated 
with it Cleais VALID on a NEGEDGE Checks for slow Logic NEGEDGE If VALID is 
high, then SAMPLE pulses high prior to the SYSCLK associated with VALID If VALID 
is low then a NEXTEDGE signal is set high, causing SAMPLE to pulse prior to the next 
fast POSEDGE 

PREV_S AMPLE = 0 sets variables to 0 

PR£V_A = 0 
PREV_BL = 0 
NEXTEDGEA = 0 

for (n = 0) -> (n = NO_OF_STATES-l ) { 

SAMPLE|n| = o //initialise sample signal arra\ to zero 
CURR_A = CLKA[n| 
CURR_BL = CLKBLftt] 

if ( PRE V_A = ())&& ( CURR_A = 1 ) store POSEDGE value of'CLKA 

POS_VALID_A = n 

else if (PREV_A = 1 ) && (CURR_A = 0) reset if NEGEDGE of'CLKA 
POS_VALID_A = 0 

if ( PREVBL = 1 ) && ( CURRBL = 0) { if NEGEDGE ofCLKBL 
if (POS_VALID_A '=()) I 

it PCS f'ALID A is set ovewnte the 

value of SAMPLE Lit the rwu indexes- given 

S AMP LE [POS_V ALID_A - 1 ] = 1 & re set POS^ VALID A 

SAMPLE [POS_VALID_A] = 0 
POS VALID A = 0 
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! else if (POS_VALID_A = 0) { 

if POS J 'A LID A /s nor. set then set NEXT_EDGE 
NEXT_EDGE_A = 1 

t 

\ 
i 

if (PREV_A = 0) && (CURR_A = 1) &&<NEXT_EDGE_A = 1) { 

SAMPLE[n-l | = 1 // POSEDGE A and NEXT EDGE _A ts set 

SAMPLE|n| = 1 previous current SAMPLE to 1 
NEXT_EDGE_A = 0 //to I Reset the NEXT_EDGE variable 

PREV_A = CURR_A[n] set the PREV variables to CURRENT values 
PREV_BL = CURR_BL[n] 

Example Divide-b>-2. Di\ide-b\-5 and Dmde-by-6 

This example shows the necessan, states and signals for a Dmde-b\-2 block 
communicating with Dmde-b\-5 and Dmde-b\-6 blocks This state machine will require 
30 slates (LCM of 3 numbeis) 

Figures 5 and 6 illustrate the progression of states and the timing diagram for the 
corresponding state machine 

High Le\el Clock Functions 

Topical high le\el clock functions are shown in Figure 7. which illustrates a clock 
generation block 70 Reference 71 denotes a 'clock state machine' All the Venlog 
associated with this function can be generated by the algorithms described preuously The 
parameters that are used as input to this algorithm are configurable parameters and 
diagramming rules The size and complexity of the state machine is dependent on the three 
parameters described nameh - Parent Clock, Is__Logic_Block and Dmde_B>_Ratio The 
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clock state machine takes in a synchronisation signal 73 that ensures that the generated 
clock is always in sync with the system clock A clock enable signal 74 will turn off the 
clock generator and hence power down all blocks connected to this generator 

References 72 each denote a 'clock out interface" There will be one interface per group of 
mtei connect blocks (i e arbiter, wrapper, bridge) to which the clock generation block is 
connected This interface will dm e the necessary clock signals (clock, sample, strobe etc) 
and reset signals to the connected block The Venlog for this function can be created from 
a standard template that will be instantiated within the block the required number of times 
The signal names for each mteiface should be changed to ensure that they are unique The 
width of the output clock bus within this template code will be configurable and will 
depend on the number of sample and strobe signals that need to be dm en into the 
connected block 

Creation of Bridge Logic 

The following pseudo-code describes the high le\el steps used to create the logic for a 
register bridge The parameters used m the creation of logic for a register bridge are fully 
described pre\ lously 

NAME = Unique name for this register bridge 

CLfv_SIGNALS = Reference to an object which describes the clock signals for 
this Block BASE_ADDR = The base address for the block 

MBUS_PORTS [ ] = array of connected mBus port objects of size 

NO_MBUS_PORTS 

RBUS_WIDTH = the width of the rBus 

RBUS_TARGETSf ] = array of connected rBus target objects of size 
NO_RBUS_TARGETS 

Create Clock Interface (CLK_SIGNALS) 
For (n=0) -> (n = NO_MBUS_PORTS-l) 

mBus target Logic (MBUS_PORTS [n] ) 
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Round Robin Arbiter ( NO_MBUS_PORTS) 

mBus to [Bus stale machine ( ) 
rBus initiator port ( ) 
Clock Interface! ) 

For (n=0) -> (n = NO_RBUS_TARGETS-l) 

rBus Select Logic ( RBUS_TARGETS[n] ) 

The high le\el register bridge functions are shown in Figure 8. which illustrates a register 
bridge 80 

The reference 8 1 denotes an mBus target interface The Vertlog for this function can be 
created from a standard template that will be instantiated within the block the required 
number of times The signal names for each interface should be changed to ensure that 
the) are unique The mBus target interface accepts an mBus read and write request It 
stalls the interface until the request is handled (read response or write acknowledgement) 
It wails for an access grant from the arbiter and passes the request to an rBus initiator 
interface 83 and handles the response 

Reference 82 denotes a round-robin arbiter The Venlog for this function can be created 
from a standard template The template will be configured with a parameter defining the 
number of mBus target interfaces that must be arbitrated The round-robin arbiter polls 
each mBus target interface for rBus read or write requests in a c> chc manner each time the 
rBus is idle It grants access to the rBus for the first request it finds at any mBus target 
interface 

Reference 83 denotes an iBus initiator interface and decode The Venlog for this function 
can be created from a standard template The signal names will be changed to ensure that 
the} are unique for each register bridge created The rBus initiator interface translates the 
mBus to rBus requests and Msa \ersa in the opposite direction The function will be 
parametensed with the range of addresses that it recognises The rBus initiator interface 
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looks al each addiess olTsel passed to it and decides which select line should be dm en 
high 

Reference 84 denotes select lines The top le\el register bridge block is parameterised to 
define the numbei of select lines supported The \ alue of the parameter is equal to the 
number of rBus targets connected to the rBus 

Reference 85 denotes a clock interface The Venlog for this function can be created from 
a standard template The block's external signal names would be changed to ensure that 
the\ are unique A simihar template will be used m all the interconnect blocks (i e arb. 
w rapper, bridge) The clock interface distributes the clock signal to all functions within the 
block It will route sample and strobe signals to the mBus and rBus interfaces defined for 
this interconnect block and handle a reset signal 

Creation of Arbitration Log ic 

The following pseudo-code describes the high lex el steps used to create the logic for the 
arbitration block The parameters used in the creation of logic for an arbiter are fully 
described pre\ iousl\ 

NAME = Unique name for this arbitration block 

CLKSIGNALS = Reference to an object which describes the clock signals for 
this block 

MBUS_IN_PORTS [ ] = arrax of connected mBus port objects and input port 
parameters of size NO_MBUS_PORTS 

MBUS_OUT_PORT= mBus objects which describes the mBus output port 

parameters 

MBUS_TARGETS= number of mBus targets 
Create Upwaid Path Logic UUU 
Create Clock Interface <CLK_SIGNALS) 
rBus target port ( ) 
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For (n=0> -> (n = NO_MBUS_PORTS-l ) 

mBus Input Logic (MBUS_IN_PORTS [n] ) 
create FIFO logic (MBUS JNJPORTS [n] ) 

Create Aibiter (NO_MBUS_PORTS. MBUSLN PORTSf ]) 

mBus output poil (MBUS_OUT_PORT . NO_MBUS_PORTS) 
For (n=0) -> (n = MBUS_TARGETS-1) 

mBus Select Logic { MBUS_TARGETS) 

Create Downward Path Logic UUtt 
For <n=0) -> (n = MBUS_TARGETS-1) 
mBus Input Logic () 
create Hold FIFO and Decode Logic () 

For (n=0) -> (n = NO_MBUS_PORTS-l 

create ReadBack and Ack FIFO (MBUS_IN_PORTS [n] ) 
mBus output port ( MBUS TARGETS ) 

The mBus and rBus are point to point bi-directional buses that can operate in full or half 
duplex mode When an arbitration block is draw n and an mBus is connected to one of its 
ports there are inferred upward and downward paths along the bus Arbitration blocks 
must store multiple read and write requests on the upward path (from an mBus initiator) 
and multiple read responses and write acknowledgements on the downward path (from an 
mBus target) This split is shown m Figure 9 and 10 below The two separate paths when 
combined constitute a complete arbitration block For this reason a clock and register 
interface is onh shown m the one of the bubbles 

The high-le^ el upward path arbitration functions are shown m Figure 9 

References 91 each denote an mBus input interface The Venlog for this function can be 
created from a standard template that will be instantiated within the block the required 
number of times (in this example, three times) The signal names for each interface would 
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be changed to ensure thai the\ are unique The mBus input interface clocks in mBus read 
and write requests on the correct edge and passes the data to the FIFO buffers 

References 92 each denote a FIFO buffer The Venlog for this function can be created 
from a standard template that vwll be instantiated within the block the required number of 
times (three) The buffer sizes, dependent on the signals rdCmdData. rdCmdPhase. 
wrlnfo. urPhase and wrData as described in application No 0104828 3 are defined by 
passing a parameter into the function when it is instantiated The FIFO stores the data 
associated with the mBus requests It will stall the mBus input interface when it is full 

Reference 93 denotes an arbiter The Venlog for this function can be generated using a 
state machine algonthm The arbiter will grant access to the mBus output port based on 
this arbitration algorithm An example of such an algorithm is one where an arbiter has a 
fixed number of slots and allocates slots to input ports based on their bandwidth allocation 
and pnorit\ parameters 

Reference 94 denotes "mBus output port and decode' The Venlog for this function can 
be created from a standard template The signal names should be changed to ensure that 
the> are unique The mBus output port will pass mBus requests to the next le\el in the 
interconnect The address of the mBus target to which access is desired is passed to the 
output port The function is programmed w ith the range of addresses that it recognises 
The mBus output port looks at each address passed to it and decides which select line (95) 
should be dm en high 

Reference 95 denotes select lines The top \e\e\ arbitration block should be parametensed 
to define the number of select lines supported The \alue of the parameter is equal to the 
number of times the mBus upward path is split (number of destinations - mBus target / 
mBus input ports) 

Reference 96 denotes a clock interface The Venlog for this function can be created from 
a standard template The block's external signal names will be changed to ensure that they 
are unique A similar template w ill be used in all the interconnect blocks (i e arb. 
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wrapper bridge) The clock mteiface distributes the clock signal to all functions within the 
block It will loute the necessars sample and strobe signals to the mBus and rBus 
interfaces defined for this interconnect block It will handle reset signals 

5 Reference 97 denotes a register target interface The Venlog for this function can be 

created from a standard template that will be used onh for creating arbitration block 
iegister target mteifaces The block's external signal names will be changed to ensure that 
the\ are unique It will allow access to the configurable registers within the block 

l'i The high-level downward path arbitration functions are shown in Figure 10 

Reference 101 denotes an mBus input interface The Venlog for this function can be 
created from a standard template that can be instantiated within the block the required 
number of times The signal names for each interface will be changed to ensure that they 
15 are unique The mBus input interface clocks in mBus read data and write 

acknowledgements on the correct edge and passes the data to the hold FIFO for decoding 

Reference 102 denotes hold FIFO ^ decode The Venlog for this function can be created 
from a standard template, an instance is created for each input port on the downward path 
20 The hold FIFO stores data while the source identifier is used to decide which output port 

the response is destined for 

Reference 103 denotes a FIFO The Venlog for this function can be created from a 
standard template, an instance is created for each output port on the downward path The 
25 buffer sizes are configurable and are dependant on signals rdDataPhase and rdData as 

described in application No 0104828 3 The FIFO stores both read data and write 
acknowledgements A read back throttle is sent to the upward path arbitration functions 
when the FIFO is full 

^> Refetence 104 denotes an mBus output port The Venlog for this function can be created 

from a standard template The signal names will be changed to ensure that the> are unique 
The mBus output port will pass mBus responses to the next ^el down in the 
interconnect 
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Figure II is a schematic diagram which represents the mBus paths for a s\stem-on-a-chip 
It includes elements which can be obtained from the hbraiA and elements which will have 
to be generated as pait of the interconnect logic Figure 1 1 shows the upward paths (cores 
to target memon ) and downward paths (memon to cores) of data transactions on the 
mem on bus 

More particularly. Figure 1 1 shows nine data handling cores, namely 'Corel" to "Core9" 
and three memories denoted "Target I "Target2" and "Target3" Figure 1 1 shows a typical 
la\oul wherein "Corel". "Core2". "Core3". "Core4" and 'Core 9" can read and write from 
"Targetl" Core3". "Core4". "Core5". "Core6" and'CoreS" can read and write from 
"Target2" "Core3". "Core4" and "Core7" can read and write from "Targets" The solid 
upward mBus path extending from Arb2 is split 3 times to allow Arb2 to address the three 
separate memories In all cases where the upward mBus path is split a multiplexer (Mux) 
is required on the downward path, as shown by the dashed lines extending from the 
arbitration stages "Arb4". "Arb5" and "Arb6" b> wa\ of a multiplexer to the stage "Arb2" 
The arbitration and aggregation stages "Arbl" to "Arb6" are generated b} the interconnect 
logic as described with reference to Figures 9 and 10 All required multiplexers are 
generated automatical!) 

Creation of Core Wrapper Logic 

Preferabh there are two core t>pes that will be available m the library", viz an mBus 
initiator core (e g Ethernet. PCI. USB) and an mBus target core (e g SDRAM controller, 
flash controller) All cores contained in the library will need a wrapper similar to the ones 
described here m order to translate between the signal format and/or comentions 
employed within the core and the signal format and/or comentions emploved on the 
memon bus (mBus) and/or the register bus (rBus) Each core will have its own unique 
requirements, therefore the w rapper will a ary somewhat from core to core 

The following pseudo-code describes the high le\el steps used to create logic for an 
initiator core wrapper block The parameteis used in the creation of logic for a core are 
fulK described pre\ iolisK 
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NAME = Unique name for this Arbitration Block 
MBUS_TARGETS= number of mBus targets 
Foi (n=0) -> (n = MBUS_TARGETS-1) 
5 mBus Select Logic ( MBUS_TARGETS ) 

The high ie\ el core (mBus initiator) wrapper functions are shown in Figure 12 

121 denotes the fundamental core logic This is "handcrafted' logic that is unique to each 
10 core The tool w ill not modtfx this logic 

122 denotes a DMA engine, "handcrafted logic" that is unique to the core The tool will 
not modifs this logic 

15 123 denotes an rBus target interface, "handcrafted logic" that is unique to each core (logic 

in each core will be \eiy similar) The tool will not modify this logic 

124 denotes a clock interface The Venlog for this function can be created from a standard 
template The block's external signal names will be changed to ensure that they are 
20 unique A similai template will be used in all the interconnect blocks (l e arb. wrapper. 

bridge) The clock interface distributes the clock signal to all functions within the block It 
will route the necessan sample and strobe signals to the mBus and rBus interfaces defined 
for this interconnect block It will handle reset signals 

25 125 denotes an mBus initiator interface, "handcrafted logic" that is unique to each core 

(logic in each core will be ier\ similar) The tool will not modify this logic 

126 denotes a select line dmer The Venlog for this function can be created from a 
standard template The signal names will be changed to ensure that they are unique A 
?o similar template will be used to create the select line logic m the bridge, wrapper and 

arbiter blocks The function will be parametensed with the range of memory addresses 
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that it recognises The select line drner looks at each address passed to it and decides if 
the select line should be dm en high 

127 denotes select lines The top-le - ^! wrapper block is parametensed to define the 
number of select lines supported The \alue of the parameter is equal to the number of 
times the corresponding mBus upward path is split (number of destinations - mBus target/ 
mBus input ports) 

The high \e\ el core (mBus target) wrapper functions are shown m Figure 13 

131 denotes an mBus target interface This will be logic that is unique to each core 
although the logic in each core will be similar The tool will not modify this logic 

132 denotes a data buffet This will be logic that is unique to the core The tool will not 
modify this logic The buffer stores posted read and write requests to assist in attaining 
maximum bandw idth efficienc> 

133 denotes an rBus target interface This will be logic that is unique to each core 
although the logic in each core will be similar The tool will not modify this logic 

134 denotes a clock interface The Venlog for this function can be created from a standard 
template The block's external signal names will be changed to ensure that they are 
unique A similar template will be used in all the interconnect blocks (i e arb. wrapper, 
bridge) The clock interface 134 distributes the clock signal to all functions within the 
block It will route the necessary sample and strobe signals to the mBus and rBus 
intei faces defined for this interconnect block It will handle reset signals 

135 denotes the core logic This is logic that is unique to each core The memory 
controller can be configured to interface to different size memories (8. 16. 32) so long as 
the memory proudes the same functionally 
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Ail core wrapper blocks will be designed with an rBus interface and one or more mBus 
interfaces In addition a single mBus can be split to multiple destinations using select 
lines The cores will then be incorporated into the libran and can be used in a multiplicity 
of different designs In a design it ma\be decided that a particular interface is not needed 
(i e onh communicate with a UART block o\er the rBus) The compiler will 
automatical!) handle the circumstances where signals need to be tied off 

Addition to Instantiation File 

The interconnect logic generated will be completely 'flat", i.e. all blocks will be 
instantiated at the same lex el. One top-level instantiation file will be created. Each block 
ithin the interconnect will be listed m the file The top-le\el input and output signals will 
be extracted from each of the interconnect blocks and declared in the top-level 
instantiation file The following information will be extracted for each signal 

(a) Signal Name 

(b) Signal Width 

(c) Signal Direction 

(d) Is it an External Signal (Pin out) 

(e) Value to tie an Input signal to if it is unused 

The parameters described prewoush will be declared and passed into each of the 
interconnect blocks The following section contains an example of a Venlog module and 
how that module would be declared at a higher lex el 

The following shows an example of a Verilog module and a top level instantiation file. 



module foo (in_sig, elk, rst, out_sig); 

input in_sig; wire in_sig; 

input elk; wire elk; 

input rst; wire rst; 

output o u t _ s i g ; reg o u t _ s i g ; 



always @ (posedge elk) 
b e gin 
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module foo 


test top; 


r e g 


SystemClock ; 


wire 


in s i g ; 


wire 


elk ; 


wire 


r s t ; 



wire o u t _ s x g 



Sample Venlog 



The following ts some exemplary Venlog showing the type of Venlog that will generate 
for the clock state machine 



module strobe_generation ( elk. RESET. clk2. strobe[TARGET_TOTAL-l:0], 

clrStro be [TARGET JTOTAL- 1 0] 
sample[TARGET_TOTAL-1.0]): 

parameter TARGET_TOTAL - 2. I! Parameters 
input parent_clk 

parameter 1 2 01 Staled = 29'b0. Statel = 29"bl0. State2 =29"bl00. 
reg [2 0] current_state. ne\t_state. 



alwa\s a.(RESET) 
begin StartO_comb 

strobe_ne\t <= strobe. 

clrStrobe_ne\t <= clrStrobe. 

sample_ne\t <= sample. 



if (RESET = 1) 

begin strobe = 0. sample = 0. clrStrobe = 0: next_state = Statel : end 
else begin 

case (current_slate) 
StateO 

begin clk2 <= 0. strobe <= 2'b00. clrStrobe <= 2"bl0. 
sample <= 2"bl 1. ne\t_state <= Statel. end 
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State I 

begin clk2 <= 1. strobe <= 2"b00. clrStrobe <= 2'blO. 
sample <= 2'bl 1 . next_state <= State2. end 

State2 

begin clk2 <= 0. strobe <= 2'blO. clrStrobe <= 2"b01. 

sample <= 2"b00. ne\t_state <= State3. end 
default 

begin ne\l_state <= Statet). end 
endcase 

end 

end 

end module 



